home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Linux Cubed Series 7: Sunsite
/
Linux Cubed Series 7 - Sunsite Vol 1.iso
/
system
/
filesyst
/
dosfs
/
dmsdosfs.000
/
dmsdosfs
/
dmsdosfs-0.6.9b
/
doc
/
troubleshooting.doc
< prev
Wrap
Text File
|
1996-07-29
|
13KB
|
248 lines
troubleshooting.doc
This file contains solutions to common problems with the dmsdos driver.
It is mostly based on the feedback of dmsdos users that mailed me for some
hints (thanks a lot to all of you!).
------------------------------------------------------------------------------
If you have problems, you may have found a bug. But check the following
list before (it is a collection of problems I have been reported and, I
think, can be solved easily). See also file BUGS for a list of known bugs.
*** See also your kernel log for 'DMSDOS:...' messages. Each message is
explained in file messages.doc. There you can find hints how to
solve the problems, too.
- It does not install/compile!
Did you run the appropriate INSTALL script? Use INSTALL_1.2 for Linux 1.2.XX
and INSTALL_1.3 for Linux 1.3.XX kernels below 1.3.39. For newer kernels
try the INSTALL_1.3.4x or INSTALL_1.3.8x script. I have tested this dmsdos
version under Linux 1.2.10, 1.2.13, 1.3.24, 1.3.45 and 1.3.81 myself
successfully and I've been reported that it works with a lot of other
versions too (the list would be too long to include it here). It compiled
under gcc 2.5.8 and 2.6.3 without any trouble. Try the same configuration,
and *please* tell me which versions you used when it failed so I can try to
fix the problem.
Please also note the awk problem that may break 'make dep'. It is
explained in Chapter 'Installation' (see file dmsdos.doc).
- I cannot find the CVF subdirectories after mounting with type
dmsdos or umsdos, I only see the CVFs as large files.
There was a problem with the CVF(s) that were not converted to
subdirectories. See your kernel log (/var/adm/messages) for details.
Only for umsdos users: Did you configure your kernel to support
doublespace/drivespace in umsdos partitions?
- I cannot write to files, delete files, create directories ... in the
compressed subdirectories.
Lots of possibilities here -- watch your kernel log for a DMSDOS error
message that may explain what went wrong...
* Have you disabled write access at compile time? (If you don't know about
this you haven't.) Then you'll find an "illegal write access" message.
* Did you mount read-only (option ro or comp=ro)?
* Only for umsdos users: Be sure to give write permission to the CVF
main directories (chmod +w directory).
* Is your compressed partition almost full? The driver refuses to allocate
new clusters on a partition that is almost full when it thinks further
write access may be dangerous and might cause data loss. Delete some
files and retry.
* The compressed partition may have errors. The driver sets errorneous
compressed partitions to read-only immediately after mounting them.
However, you can allow write access again by setting the comp parameter
via dutil (example: 'dutil /DOS/dblspace.001 setcomp guess'). Of course,
it is not recommended to write to errorneous partitions.....
- When trying to write to a compressed filesystem I receive I/O errors.
See previous problem. If you think it's another reason, run dutil to check
whether the filesystem is full or too fragmented. If the compressed
filesystem is read-only but the underlying dos filesystem is read-write,
all write access to the compressed filesystem is refused. There is, of
course, no real I/O error. (The dmsdos driver returns the 'permission
denied' error code, but some applications claim 'I/O error' instead.)
- When trying to write to the compressed partition, I receive "no space left
on device" errors though dutil says there's *a lot* of free space (>100KB).
You have run out of clusters. This is new since dmsdos version 0.6.8: the
driver ensures that you don't get more clusters than dos would give to
you (otherwise dos' scandisk.exe would *destroy* the compressed partition
the next time it checks it by inventing some strange errors and trying to
correct them [arghhhh... seems to be a scandisk bug]). Two solutions are
possible:
* Boot dos, run dblspace.exe or drvspace.exe, set the compression ratio to
the value the program suggests. Don't be surprised if it suggests high
compression rates you aren't used to from dos - it's because dmsdos
compresses a little better than dos itself. (In fact, you needn't
believe the value dos claims - it's exaggerating sometimes....)
* Set a higher cluster limit with dutil. (*WARNING*: This is experimental
and hasn't been tested thoroughly yet. In fact, you can set *any*
limit you want - but it may confuse dos later.) Example:
'dutil /DOS/dblspace.001 setmaxcluster 1000' sets the cluster limit to
1000. The actual cluster limit can be obtained with dutil (example:
'dutil /DOS/dblspace.001', watch for the "max_cluster" value) or with
chkdsk.exe under dos (take the number of clusters + 1).
Both alternatives are supposed to be identical - the dutil setmaxcluster
command has been implemented in order to solve the problem without having
to boot dos, but it is currently experimental.
- A file I want to read appears to be empty but the directory says it is not
empty.
There was a problem decompressing the file. See your kernel messages
(/var/adm/messages). The first thing to do is to boot dos and run the dos
filesystem checker on the compressed partition (do not skip the surface test
since only this test finds erros in compressed data). After that, reboot
Linux and retry. If the problem did not disappear this may be a real
dmsdos bug and should be emailed to the author. If you are running
drivespace 3 under win95 you may encounter this problem quite often because
it isn't fully supported yet (it's the drivespace 3 'Ultra' compression
scheme dmsdos can't read).
- My Slackware version refuses to boot because it does not find a fsck.dmsdos
Find the file fsck.msdos (should be in /etc/fs) and create a link
fsck.dmsdos that points to fsck.msdos. I have never seen such a Slackware
version but I have been reported that some older Slackware versions need
it. You should upgrade to a newer version because this behavior is quite
critical.
- The command 'df' does not tell how much free space is on the compressed
partitions.
This is because the kernel treats all the CVFs and the real underlying
msdos partition as one partition. So it displays only the free space
on the real msdos part. The space allocated by a CVF is reported as
fully allocated (because it *is* occupied by a large file: the CVF). Run
the external dmsdos utility dutil on the compressed partition to see how
much space is available inside a CVF. Example: 'dutil /DOS/dblspace.000'
(you may specify any directory inside the CVF you want information about).
- I compiled in write access, mounted a compressed floppy at /mnt with
option comp=no (or similar) as type umsdos and tried to run umssync on
the disk. It failed with an error message and now some or all files are
gone (help)!
You cannot umssync a compressed floppy without freeing up some space for
the umsdos special file --linux-.--- (the real msdos part of a compressed
floppy is always totally full).
But you have luck, the files are not gone at all. Unmount the floppy and
mount it as type dmsdos. Then remove the (empty) file --linux-.--- and the
'readme' or 'readthis' or whatoever (it contains a message that this disk
is compressed and that you must run Micro$ doublespace to read it ...
very interesting - and not true at all: you can use Linux and dmsdos
instead :-) ). Now there should be some bytes free for umsdos. Unmount
the floppy again, mount it as type umsdos and retry. If the problem
appeared inside the compressed partition, also mount as type dmsdos, remove
--linux-.--- where files were gone, free up some space, mount again as type
umsdos, and retry running umssync.
- The utility dutil reports a different compression ratio and different free
space than dos.
The utility uses another method to calculate the compression ratio and the
amount of free space. Well, dos displays a dream ratio, dutil exactly
determines how much the files shrunk on compression. Dos' ratio is higher
because it compares the space the files *have* allocated with the space
the files *would have* allocated on an uncompressed partition with an 8 KB
(32KB under drivespace 3) cluster size. The slack at the end of the files
causes the difference (especially on small files), but saving wasted space
is not the same as compression (I think). Since the ratio is used to
estimate the free space, this value is also different.
- The external utility dutil displays garbage.
Did you change the '#define MAXFRAGMENT' in dmsdos_fs.h ? Then you *must*
recompile dutil, too. You may have an old version of dutil somewhere in
your path, find and delete it and recompile dutil. If dutil displays just
zeros, you are definitely running a dutil from an older dmsdos version.
Remove it and recompile the source.
- My compressed partition under win95 fails!
It's not win95, but it's the drivespace 3 format that is not yet fully
supported due to lack of documentation. You may even encounter serious
problems (unreadable files and corrupted directories that confuse the
dmsdos driver and might cause strange things). Currently, you cannot read
files compressed with the 'Ultra' compression method (I simply don't know
how to decompress them) and you can't access fragmented clusters.
Recompress to 'High' and defragment your drive. See your drivespace 3
documentation how to do so.
- The external dmsdos utility displays some "lost clusters", but dos'
scandisk says everything is okay.
The term "lost clusters" doesn't mean that the clusters are not assigned to
a file (like in a normal dos fs). Instead, it tells there are clusters that
have been allocated in the FAT but have a zero MDFAT entry. This is not a
filesystem error, it only means that the clusters do exist, but they don't
contain any data and therefore don't use disk space. So they aren't really
used, but they aren't free either. This is a special situation that can only
occur in a compressed filesystem. These lost clusters may result
from situations where the filesystem got too full (i.e. the driver had to
throw away the data it couldn't write to the full filesystem).
- I can't see long filenames on my win95 partitions, I only see the short
ones.
If you cannot see long filenames in a compressed partition: In this dmsdos
version auto-detection of long filenames has been disabled. Try mounting
with option 'long=on'. If you want to see long filenames in the uncompressed
host partition, try mount option 'vfat' (please note that you must have
configured your kernel appropriately during 'make config').
- I've created a new compressed filesystem with 'mkdir /DOS/dblspace.002'
but dos doesn't mount it.
You haven't really created a compressed partition, but you have created
a usual directory /DOS/dblspace.002 (which you *can* see under dos). Use
dos to create new compressed partitions (but remove the stale dblspace.002
directory first becuse it may confuse dos).
- My filenames are upper case!
This is because long filename support has been turned on. If you don't have
long filenames (e.g. because you use dos <= 6.22) the driver may have failed
to auto-detect this. You can disable long filename support inside a
compressed partition with the mount option 'long=off'. If you don't want to
disable long filename support, but you want lower case short names, try
option 'low'.
- The dmsdos or umsdos module fails to load and complains about undefined
symbols instead (only for kernels > 1.3.8x).
Please note the complex msdos filesystem hierarchy (only kernels > 1.3.8x).
The '->' means 'depends on', i.e. must be loaded before or must be part
of the kernel.
A. Without dmsdos.
umsdos -> msdos
vfat -> fat
msdos -> fat
B. With dmsdos, no vfat support in uncompressed part, no DoubleSp/DriveSp
support in umsdos partitions.
umsdos -> msdos
vfat -> fat
msdos -> fat
dmsdos -> msdos
C. vfat support in uncompressed part.
*additional* to B: dmsdos -> vfat
D. DoubleSp/DriveSp support in umsdos partitions.
*additional* to B: umsdos -> dmsdos
Usually try to load the modules in the following order: fat, msdos, vfat,
dmsdos, umsdos. Unload them in reverse order.
- I cannot unmount my dmsdos partition. umount complains with "device busy".
Some process is currently using a file or a directory of your partition.
If you have started the dmsdos daemon, you cannot unmount the partition
which you specified as argument in the dmsdosd command line. In this case,
you must kill the daemon before with SIGINT or SIGTERM.